---
title: Authoritative-only name server on Debian
x-toc-enable: true
...

Introduction
============

This guide was last tested on Debian 11.

Refer back to the [main section](./) for context. In this guide, we will
configure an authoritative-only DNS server for your server hosting. Typically,
when you configure web hosting, you will enter e.g. `ns1.domain.com`
and `ns2.domain.com` for the name servers, and most people will use the name
servers provided by their *domain name registrar*, even if they do host their
own servers. The individual would then enter domain zone file information, such
as A/AAAA, CNAME or TXT records. If you're using a more automated *shared
webhosting* provider, they might automate DNS configuration for you.

In this tutorial, we will be doing it *ourselves*, the old-fashioned way. We
will *not* be configuring a fancy web interface. We will edit DNS zone
files *directly*, in a [text editor](https://www.vim.org/).

The term "authoritative-only" refers to the fact that this name server
will *only* be used to resolve hosts your *your* own domains; it will be
configured *not* to resolve anything else, as then it would be an open
resolver. You *can* run an open resolver if you wish, and Fedfree may cover it
at some point, but that is beyond the scope of *this* article (and if you do,
you should not run it on the same host as your authoritative name server).

Let's dive straight in.

Requirements
============

IP addresses
------------

It is assumed that you have *two* IPv4 addresses and *two* IPv6 addresses,
all assigned to the same host, publicly routed with port 53 *open*.

You *need* at least two IPv4 addresses, and *two* IPv6 addresses if also
running IPv6. If you need static IPs, you might consider a set up such as
what is described in the [router section](../router/) on the Fedfree site.

Side note: if you're using the L2TP tunnel setup described
on [router/debian-l2tp-aaisp.md](../router/debian-l2tp-aaisp.md), you could be
very naughty indeed: use the *router* IPv4, on WAN side (single allocation),
for ns1, and the subnet IPv4 (e.g. /29 one) LAN side. In so doing, you do
not waste more IPv4 addresses. For IPv6, just use one of the /64 ones from
the allocated subnet A&A gives you. You can run L2TP and DNS on the same host.

Domain name
-----------

You need a *domain name*, such as `example.com`, and your registrar must
support setting *glue* records (including IPv6 ones).

The registrar [gandi.net](https://www.gandi.net/) is *excellent*, and meets
this criteria. It is a *solid* company, very friendly to libre software
projects.

This list contains references to many registrars, including Gandi. On this
list, you may find ones that support IPv6 Glue:

<https://www.sixxs.net/faq/dns/?faq=ipv6glue>

You should *also* make sure to get one that supports *DNSSEC*. While this
tutorial does *not* cover DNSSEC, it shall be documented in a follow-up guide.

If you're using a registrar that *supports* setting glue records, but only
on IPv4, you can *still* run a name server on dual stack, but IPv6-only users
may not be able to access your services; if the resolver that they're using
nonetheless has an IPv4 connection to the internet, it would find things like
AAAA records pointing to IPv6 hosts, and your IPv6 web server would work, for
example. *Really though, you should consider a domain transfer, if your
registrar is that bad. Some don't even let you set glue records at all, on v4
or v6!*

Glue records
------------

Log in to your domain name registrar account, e.g. Gandi account, and
look for a section pertaining to your domain name. In *this* guide, I'm going
to use my domain name `shlinux.org` as an example, because I own that domain
and I run these on it: `ns1.shlinux.org` and `ns2.shlinux.org` - the Fedfree
site uses *these* name servers, for its DNS configuration. *I myself* run my
own DNS, using a setup virtually identical to what is described on this page.

Normally, if you outsource your DNS hosting, you just set the NS record for
your domain name, in your registrar login, specificing `ns1.domain.com`
and `ns2.domain.com`, or whatever you have; here, you are only specifying
names.

Because you're running your *own* DNS, you must *also* specify an IP address,
in the *glue record* for your target domain. You do *not* have to use the
same top-level domain name for the two name servers, but for simplicity we
will assume that you are going to use the same domain.

The *glue record* exists because the NS record is still set accordingly,
but it's referring to itself. The glue record is basically equivalent
functionally to an A/AAAA record.

Set the glue records to all those IPs which you intend to use. In my
example, I have these records (on my Gandi account, which I use for my
own name servers):

* `ns1.shlinux.org` (IPv4): `81.187.172.130`
* `ns1.shlinux.org` (IPv6): `2001:8b0:b95:1bb5::2`
* `ns2.shlinux.org` (IPv4): `81.187.172.131`
* `ns2.shlinux.org` (IPv6): `2001:8b0:b95:1bb5::3`

You must **also** still set the usual NS records. I set my name servers
for `shlinux.org` to `ns1.shlinux.org` and `ns2.shlinux.org`, and the glue
record makes it work.

The name server *itself* shall also declare the name NS records, and A/AAAA
records, thus: ns1, ns2 (correct for the above example, but you should
adapt accordingly). More on this later.

Software installation
---------------------

Install Debian, on the target machine. You must configure it, so that it
has 2 public IPv4 and 2 public IPv6 addresses, directly pingable from the
internet on all addresses, with *port 53* open on *all of them*.

If you need a tunnel connection, for routing static IPs to your machine,
you may check the guides in the [router section](../router/).

Great! Now install bind9 on the machine. We shall configure ISC's `bind9`.
Install it with the package manager:

    apt-get install bind9

Bind9 configs
-------------

We will *not* be configuring a slave name server, in this tutorial; such will
be covered later as a follow-up to this one. In *this* guide, we will assume
that bind9 master and slave are both running on the same host, with 2 public
IPv4 and 2 public IPv6 addresses allocated. This technically means that there
is *no slave*, but it does work, so long as you have 2 IPv4 and (if using
IPv6) 2 IPv6 addresses assigned on your host, all publicly routed with
port 53 open.

For your convenience, Fedfree has *included* reference configs for you to
use, on the Fedfree website. You may simply download it and install it:

Download this file: [debian-bind-no-slave.tar.xz](debian-bind-no-slave.tar.xz)

NOTE: The sample configs do *not* provide for DNSSEC, nor will DNSSEC be
configured in *this* tutorial; such will be covered, in a follow-up guide.

Extract it:

    tar -xf debian-bind-no-slave.tar.xz

You should have have a directory named `bind`. This is a series of sample
configurations, but they are actually *used* in the real world, for my
hosting (at least in December 2022). I've not included *all* zone files in
there, for all domains, because that would be excessive for the purpose of this
tutorial.

DO NOT simply use these configs as-is, of course. They won't work for you,
because they contain configuration for my IPs and domains. In the next
sections, we will go through everything.

Configuration
=============

Install the sample configs
--------------------------

Firstly, with bind9 already installed, delete `/etc/bind` like so (as root):

    rm -Rf /etc/bind

You will replace the `bind` directory in `/etc`, with the `bind` directory
that you *just* extracted, from `debian-bind-no-slave.tar.xz`

Like so (as root):

    cp -R bind /etc/bind

In the next sections, we will cover various files, explaining what they are
and, where modifications are required, what to modify.

/etc/bind/bind.keys (do not modify)
-------------------

This file is provided by the *Internet Systems Consortium*, and should not
be modified directly. It contains keys which override the built-in ones
that bind9 comes with. These are used for the 13 root name servers that
exist (`a.root-servers.net`, `b.root-servers.net`... all the way up
to `m.root-servers.net`) which handle top level domains. DNS is centralised,
but NS/Glue records are set upstream which delegate to an authoritative
name server for your zone, e.g. `example.com`.

Again, *never* modify this file directly. However, you check should at least
once every month for a new version. It doesn't change often, but you can find
newer versions of this file here:

<https://www.isc.org/bind-keys>

The version provided by Fedfree, identical to the one taken from ISC, was
up to date as of 25 December 2022.

/etc/bind/db.root (do not modify)
-----------------

This file defines what the root name servers are. On the internet, there
are *13* of them, starting from `a.root-servers.net`,
to `b.root-servers.net`... all the way to `m.root-servers.net`.

This file should *not* be modified directly. It is provided by InterNIC, and
you should check for updates at least once every month (it doesn't
change very often, but once per month should be more than thorough enough).

You can find updated versions on `ftp.internic.net` (FTP protocol) in the
directory `/domain/`, file name `named.cache`.

The version provided by Fedfree, identical to the one takes from InterNIC,
was up to date as of 25 December 2022.

/etc/bind/db.127 (do not modify)
----------------

Zone file for IP address (zone) `127.0.0.1`, resolving to localhost.

/etc/bind/db.empty (do not modify)
------------------

Zone file for empty RFC 1918 zone.

/etc/bind/name.conf.default-zones (do not modify)
---------------------------------

localhost forward and reverse zones. (RFC 1912 compliance)

/etc/bind/named.conf.options (do not modify)
----------------------------

This file *does not* need to be modified. Explaining some of the settings
inside it:

    allow-transfer { none; };

The `allow-transfer` line pertains to master and slave. Because we're not
configuring a slave, we can ignore this entirely.

    recursion no;

If `recursion` is enabled, this would become a *resolver*, the kind you
would set up for resolving any domain name on the internet. We only want
this to be an authoritative domain name server, for *our* domains, so this
is set to `no`.

    dnssec-validation auto;

This pertains to DNSSEC, when *we* are resolving names from *other* name
servers. This setting is entirely irrelevant, for the purposes of the
tutorial. We can leave this alone (but please do leave it there).

    auth-nxdomain no;

If `auth-nxdomain` set to `yes`, our server would respond authoritatively
even for zones not in our control. We only want it to be authoritative
for *our* zones, so we set this to `no`.

    listen-on-v6 { any; };

This one should be self-explanatory. It enables BIND to listen on IPv6
addresses. We *want* dual stack IPv4 and IPv6 operation, so the
the `any` setting makes this work accordingly.

/etc/bind/db.0 (do not modify)
--------------

Reverse rules for broadcast zone (zero addresses). Leave this as-is.

/etc/bind/db.255 (do not modify)
----------------

Ditto.

/etc/bind/db.local (do not modify)
------------------

Forward rules for local loopback addresses e.g. `127.0.0.1` or `::1`,
resolving to `localhost`.

/etc/bind/named.conf
--------------------

This is the main configuration file for bind9. In our case, using the
sample files, this simply links to sub-configuration files such
as named.conf.options as described above.

File contents, for reference:

```
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
```

/etc/bind/named.conf.local
--------------------------

*This* file is important. In here, we define zones e.g. `shlinux.org`.
For each specified zone, the path to a *zone file* is defined.

Please pay close attention.

File contents, in our reference configs:

```
zone "libreboot.org" {
	type master;
	file "/etc/bind/zones/db.libreboot.org";
};
zone "shlinux.org" {
	type master;
	file "/etc/bind/zones/db.shlinux.org";
};
zone "fedfree.org" {
	type master;
	file "/etc/bind/zones/db.fedfree.org";
};
zone "130.172.187.81.in-addr.arpa" {
	type master;
	file "/etc/bind/zones/db.ipv4ns1";
};
zone "2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.b.b.1.5.9.b.0.0.b.8.0.1.0.0.2.ip6.arpa" {
	type master;
	file "/etc/bind/zones/db.ipv6ns1";
};
```

Remove the libreboot/shlinux/fedfree entries and put your own ones in there,
for your domain names. In this guide, we will assume that you place your own
zone files under the directory `/etc/bind/zones`. The zone files shall
contain within them, all DNS entries such as AAAA/A, NS, TXT, CAA and so on.
Information about what goes in these files will be covered later on in the
guide.

In the above entries, you see the final two look very strange indeed!

These are reverse zones, for IP addresses. These are taken (on 25 December
2022) for the `ns1.shlinux.org` name server. On that day, it had these IP
addresses:

* `81.187.172.130` (IPv4 `ns1.shlinux.org`)
* `81.187.172.131` (IPv4 `ns2.shlinux.org`)
* `2001:8b0:b95:1bb5::2` (IPv6 `ns1.shlinux.org`)
* `2001:8b0:b95:1bb5::3` (IPv6 `ns2.shlinux.org`)

We *will* cover those zone files first, when we get to zone files. For now,
you should modify the file `named.conf.local` like so:

Your ns1 IPv4 address first: run this command:

    host IPv4address

You will get an `in-addr.arpa` address, much like the above. For the entry
pertaining to `db.ipv4ns1`, set the `zone` name accordingly. For example,
the IP address 1.2.3.4 would become `4.3.2.1.in-addr.arpa`.

The IPv6 address `2001:8b0:b95:1bb4:4` entry, for the part pertaining
to `db.ipv6ns1`, would
be: `4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.b.b.1.5.9.b.0.0.b.8.0.1.0.0.2.ip6.arpa`

You will note that the IP addresses are *backwards*, in the above examples.
These are the built-in reverse DNS entries for your IPs. All IPv4 and IPv6
addresses have them.

Taking the two fictional examples as above, we would modify those entries,
thus:

```
zone "4.3.2.1.in-addr.arpa" {
	type master;
	file "/etc/bind/zones/db.ipv4ns1";
};
zone "4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.b.b.1.5.9.b.0.0.b.8.0.1.0.0.2.ip6.arpa" {
	type master;
	file "/etc/bind/zones/db.ipv6ns1";
};
```

In the IPv6 example, it's backwards and each *digit* of the hexademical groups
of 4, are dot-separated. So for example, `2001:` at the start of an IPv6
address (as in the above example) is `1.0.0.2.ip6.arpa` at the end of the
string.

It should be noted: in this guide, for IPv6, we are using the deprecated
ip6.arpa format alongside AAAA addresses, as opposed to the newer A6/DNAME
entries; in practise, the old way works just fine, and it's simpler. It will
never *not* work, and I'm therefore not going to make my life more difficult
because some jackasses said so. More information about that is available here:

<https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_16.htm>

A6 records could be covered at a later date, but they are (for now) not
covered in this guide.

/etc/bind/zones.rfc1918
-----------------------

These are *unused* in our example configuration, but they pertain to
[RFC 1918](https://www.rfc-editor.org/rfc/rfc1918)

Enable it or don't. It's up to you. Uncomment the line for it
under `named.conf.local`.

Zone file configuration
=======================

Let's talk turkey.

First of all, BEFORE configuring domain names, we must take care of the
files `db.ipv4ns1` and `db.ipv6ns1`. We will cover *these* first, and then
we will cover the domain name used for running your name servers (again, we
assume that you are running `ns1` and `ns2` on the same domain name).

/etc/bind/zones/db.ipv4ns1
--------------------------

The file name has "ns1" in it, but this file shall contain `PTR` and `NS`
records pertaining to both `ns1` and `ns2`. In the sample files provided, you
shall see:

```
;
; BIND reverse data file for local loopback interface
;
$TTL	604800
@	IN	SOA	shlinux.org. leah.libreboot.org. (
			 20221226	; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL

; Name servers
        IN      NS      ns1.shlinux.org.
        IN      NS      ns2.shlinux.org.

;ptr records
130     IN      PTR      ns1.shlinux.org.
131    IN      PTR      ns2.shlinux.org.
;
```

Firstly, observe these lines:

```
        IN      NS      ns1.shlinux.org.
        IN      NS      ns2.shlinux.org.
```

Change these to whatever your own name server zones are to be. For
example, `ns1.boobworld.com` and `ns2.boobworld.com`.

Now observe these lines:

```
130     IN      PTR      ns1.shlinux.org.
131    IN      PTR      ns2.shlinux.org.
```

In our sample configs, we configure `ns1.shlinux.org` and `ns2.shlinux.org`
which, respectively, correspond to `81.187.172.130` and `81.187.172.130`.
These IP addresses are of `/28` subnet size (32 take 4 makes 28; 2 to the
power of 4 is 16, then you take the subnet+broadcast address and router
address within the subnet, which would then yield 13 useable IP addresses).

Remember, the IPv4 address `81.187.172.130` corresponds
to `130.172.187.81.in-addr.arpa`; in this case, becasue it's a /28, but
because that is within the `130` octet, you can therefore think
of `130` as kind of like a *subdomain* of `72.187.81.in-addr.arpa` (this is
not technically correct, but a useful analogy).

So, the `130` "hostname" in the zone should have a PTR record set,
corresponding to `ns1.shlinux.org`. The PTR record is sometimes referred to
as "reverse DNS".

Same deal for the 131 entry.

Please also observe:

```
			 20221226	; Serial
```

The serial line *must* be changed, whenever you modify a zone file. Use
of an ISO date is recommended (YYYYMMDD), but you can put almost anything
there.

You *must* modify this file, according to *your* IP addresses and zone name.

/etc/bind/zones/db.ipv6ns1
--------------------------

This file accomplishes the same thing as `db.ipv4ns1` but for IPv6.

In our sample files, we see:

```
;
; BIND reverse data file for local loopback interface
;
$TTL	604800
@	IN	SOA	shlinux.org. leah.libreboot.org. (
			 20221226	; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL

; Name servers
       IN      NS      ns1.shlinux.org.
        IN      NS      ns2.shlinux.org.

;ptr records
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0     IN      PTR      ns1.shlinux.org.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0     IN      PTR      ns2.shlinux.org.
```

Most of these entries are precisely the same. In fact, all of them are,
but the rules for IPv6 are different:

Take the line that says `2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0`, for instance:

This line corresponds to `2001:8b0:b95:1bb5::2`. The `::` is shorthand,
but the full address would
be: `2001:08b0:0b95:1bb5:0000:0000:0000:0002`. Remove the : characters and
separate each digit by dots, we would
get: `2.0.0.1.0.8.b.0.0.b.9.5.1.b.b.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2`.

Reverse these digits, and we would
get: `2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.b.b.1.5.9.b.0.0.b.8.0.1.0.0.2`

This IPv6 address happens to be of prefix size `/64`, and IPv6 addresses
are 128 bits in size, so basically we cut off half:

* `2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0` shall correspond via PTR record,
  to `ns1.shlinux.org`

Same for ns2, using the same method by its IPv6 address
of `2001:8b0:b95:1bb5::3`.

You *must* modify this file, according to your own IPv6 addresses and
zone name.

More information about this is available here:

<https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_16.htm>

/etc/bind/zones/db.shlinux.org
------------------------------

*This* zone file is for `shlinux.org`, on which the sample files also
configure `ns1.shlinux.org` and `ns2.shlinux.org`. You must specify your own
file for the domain name that you use, replacing `db.shlinux.org`.

In the sample file (actually used in production on 26 December 2022, for
shlinux.org), you shall see:

```
;
; BIND data file for local loopback interface
;
$TTL	604800
@	IN	SOA	ns1.shlinux.org. leah.libreboot.org. (
		       20221230		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
;
shlinux.org.	IN	NS	ns1.shlinux.org.
shlinux.org.  IN      NS      ns2.shlinux.org.
shlinux.org.	IN	CAA	0 issue "letsencrypt.org"
shlinux.org.	IN	CAA	0 iodef "mailto:leah@libreboot.org"
ns1		IN	A	81.187.172.130
ns1		IN	AAAA	2001:8b0:b95:1bb5::2
ns2		IN	A	81.187.172.131
ns2		IN	AAAA	2001:8b0:b95:1bb5::3
shlinux.org.	IN	A	81.187.172.132
shlinux.org.  IN      AAAA    2001:8b0:b95:1bb5::4
www		IN	A	81.187.172.132
www		IN	AAAA	2001:8b0:b95:1bb5::4
aimbot		IN	A	81.187.172.129
aimbot		IN	AAAA 2001:8b0:b95:1bb5::1
```

As always, remember to change the `Serial` string when modifying a zone file.

Here, we see these entries:

```
shlinux.org.	IN	NS	ns1.shlinux.org.
shlinux.org.  IN      NS      ns2.shlinux.org.
ns1		IN	A	81.187.172.130
ns1		IN	AAAA	2001:8b0:b95:1bb5::2
ns2		IN	A	81.187.172.131
ns2		IN	AAAA	2001:8b0:b95:1bb5::3
```

Notice how `shlinux.org.` refers to *itself* for the two `NS` records.
This is a self-referencing domain name, and we configured the IPs in
previous sections of this guide.

*Because* this is self-referencing, our zone file specifies the regular
A and AAAA records pointing to the IPs for these names. In the case of
shlinux.org, at least on 25 December 2022, these IPs are used:

* `ns1.shlinux.org` (IPv4): `81.187.172.130`
* `ns1.shlinux.org` (IPv6): `2001:8b0:b95:1bb5::2`
* `ns2.shlinux.org` (IPv4): `81.187.172.131`
* `ns2.shlinux.org` (IPv6): `2001:8b0:b95:1bb5::3`

*For the purpose of DNS*, the only the `ns1`/`ns2` A/AAAA and `shlinux.org.`
NS records matter. It's perfectly acceptable for a zone running name servers
to also specify normal web stuff for example (`www` A and AAAA records) as
above, and it could even run email (email-related DNS records are not present,
in the above sample).

To summarise, we have:

* Specified IPv4 and IPv6 glue, in the registrar login
* Also specified NS records, registrar side
* Specified PTR/reverse zones for IPs, in bind9
* Specified NS and PTR records in domain name zone file

So, with this, all the right glue should now be in place, and you can
just use your name server!

In my case, I set NS records for domains to `ns1.shlinux.org`
and `ns2.shlinux.org`; I then create the corresponding zone files, and write
whatever records I want in there, for each domain. I host *many* domains, on
the shlinux name server. Too many. My domain names are like Where's Wally
characters, at this point, but I will never outsource my DNS hosting.

Wrapping up
===========

When you're sure that BIND is properly configured, you can start BIND:

    systemctl start bind9

You can stop it like so:

    systemctl stop bind9

You can restart it like so:

    systemctl restart bind9

Adding domain names
===================

As can be gleaned from the above sections, edit the
file `/etc/bind/named.conf.options` and specify the domain, with a path
to the zone file.

You will then create that zone file.

For more general guidance about non-self-referencing zone files, please refer
to [zonefile-bind.md](zonefile-bind.md)

You will *also* find other example zone files, in the sample configs
that you used when following this guide. Feel free to use them as
a reference.

Testing
=======

Basically, these programs can be used in various ways to test your
domains, as configured in the name server:

* `dig`
* `host`
* `ping`

Check the manuals, for these programs. They will be available on whatever
Unix system you have such as Linux or BSD.

Reverse DNS, ISP side
=====================

*WE* have also configured reverse DNS, but your ISP is the one
that assigns IP addresses, whether that be a hardline or a tunnel
provider.

You might want to set PTR/rDNS records, just for fun.

Do this:

    host 81.187.172.130
    host 81.187.172.131
    host 2001:8b0:b95:1bb5::2
    host 2001:8b0:b95:1bb5::3

You will find that these actually correspond to `ns1.shlinux.org`
and `ns2.shlinux.org`, publicly. My name server runs in front of an
L2TP tunnel router via Andrews & Arnold Ltd (AAISP), using the same setup
as described
in [router/debian-l2tp-aaisp.html](../router/debian-l2tp-aaisp.html) - and
A&A lets you set rDNS for IPs. I've done so, for all IPs that I use.

rDNS is especially important for *email* hosting, which you will presumably
want to setup, if you're wily enough to follow this DNS guide.

Test IPv6
=========

Later on, when you've finished configuring everything, you can check IPv6
status using this excellent checker:

<https://www.mythic-beasts.com/ipv6/health-check>

Most importantly, the tester linked above checks for connectivity on an
IPv6-*only* setup, so that you know whether IPv6-only internet users can
access your services. Keep this link handy! Mythic Beasts is also an excellent
VPS hosting provider, that I may well feature in a future guide for how to
run your own OpenVPN or WireGuard tunnel server, on which to then run a
local tunnel router for home server hosting.

Debugging
=========

Any issues with BIND will be reported in `/var/log/syslog`.

Dubious mention: RNDC
=====================

BIND comes with a daemon called RNDC, which can be used to remotely
control the name server, using a secret key.

It is to be considered a security liability, for most production use,
unless configured correctly **and used properly** (this last part is
where most people screw up). An improperly configured RNDC daemon shall
permit any person on the internet to mess with your name server.

It is neither covered nor enabled by anything in this guide, nor by the
sample configurations provided.

If you have zone files in place, for a set of domains, edits to those
zone files do not require a restart of bind9. So long as the `serial`
entry is updated accordingly, you should be file, and you could edit
the zone files in a chrooted SFTP session via OpenSSH.

The RNDC daemon *can* be useful, and may be covered in a future follow-up
tutorial.

References
==========

You may find the upstream bind documentation useful. BIND is maintained by
the *Internet Systems Consortium*, and you can find the website here:

<https://www.isc.org/bind/>

The upstream Git repository, at least on 25 December 2022, can be found here:

<https://gitlab.isc.org/isc-projects/bind9>

Documentation available here:

<https://gitlab.isc.org/isc-projects/bind9/-/tree/main/doc>

There is nothing more to say. Have fun!
